home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / urn / urn-archives / urn-ietf.archive.9701 / 000016_owner-urn-ietf _Wed Jan 29 16:20:09 1997.msg < prev    next >
Internet Message Format  |  1997-02-19  |  3KB
  1. Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id QAA11095 for urn-ietf-out; Wed, 29 Jan 1997 16:20:09 -0500
  2. Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id QAA11084 for <urn-ietf@services.bunyip.com>; Wed, 29 Jan 1997 16:19:58 -0500
  3. Received: from Honey.Innosoft.Com by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
  4.         id AA07805  (mail destined for urn-ietf@services.bunyip.com); Wed, 29 Jan 97 16:19:48 -0500
  5. Received: from LOCALHOST by envy.cs.utk.edu with SMTP (cf v2.11c-UTK)
  6.           id LAA01155; Wed, 29 Jan 1997 11:13:24 -0500
  7. Message-Id: <199701291613.LAA01155@envy.cs.utk.edu>
  8. X-Uri: http://www.cs.utk.edu/~moore/
  9. From: Keith Moore <moore@cs.utk.edu>
  10. To: Daniel LaLiberte <liberte@ncsa.uiuc.edu>
  11. Cc: "Martin J. Duerst" <mduerst@ifi.unizh.ch>,
  12.         "Ron Daniel Jr." <rdaniel@lanl.gov>, Tim Berners-Lee <timbl@w3.org>,
  13.         URL mailing list <ietf-url@imc.org>, urn-ietf@bunyip.com,
  14.         moore@cs.utk.edu
  15. Subject: [URN] Re: Relative URLs and URNs 
  16. In-Reply-To: Your message of "Wed, 29 Jan 1997 09:58:08 CST."
  17.              <199701291558.JAA18910@void.ncsa.uiuc.edu> 
  18. Date: Wed, 29 Jan 1997 11:12:51 -0500
  19. Sender: owner-urn-ietf@services.bunyip.com
  20. Precedence: bulk
  21. Reply-To: Keith Moore <moore@cs.utk.edu>
  22. Errors-To: owner-urn-ietf@bunyip.com
  23.  
  24. > If all URNs are syntactically opaque URLs, are we not imposing a
  25. > restriction on all URNs that they cannot use the relative URL mechanism?
  26.  
  27. Yes, but this is a feature.  Relative URLs wire relationships between
  28. resources into the resource name itself, which hurts long-term persistence.
  29.  
  30. > Long term, support for some name
  31. > spaces will eventually fade out completely, so moving to a new name
  32. > space is not only a possibility, it seems to be a certainty.
  33.  
  34. Yes, for newly-created names.  But there's no reason why resolution
  35. services cannot continue to exist for old namespaces, even though
  36. they may use new resolution methods and protocols.
  37.  
  38. > How is a location within a resource really different from a relative
  39. > URN?
  40.  
  41. The answer depends on whether the relationship between locations within
  42. a resource can change over time.  But you're right - the ability to
  43. reference different portions of a resource opens up a very similar
  44. can of worms as the ability to reference one resource relative to another.
  45.  
  46. If you want persistent references for portions of a resource, you need 
  47. similar rules for assignment as you would for persistent identifiers 
  48. for resources themselves -- e.g. don't use section numbers (they'll change)
  49. or human-meaningful section names (because the document will be 
  50. reorganized into sections that don't correspond to the original one).
  51.  
  52. Even then, I'm not sure what it means to talk about references 
  53. relative to a "Base URN" ...because this assumes that the "Base URN"
  54. will need to change while the intra-resource reference names 
  55. need to stay the same.  
  56.  
  57. > Another advantage of relative identifiers is that they are shorter
  58. > than their equivalent full identifiers.  
  59.  
  60. It's not necessarily true that a URN is shorter than a relative URL.
  61. Since URNs don't need to be human-meaningful, they can be allocated
  62. from a denser space than is typical for URLs.
  63.  
  64. Keith
  65.